History |
Managing system security
Approaches to system security
There are many issues to consider when trying to run server machines connected to the Internet. These issues are a constant threat to the stability and useability of your servers. Defending your servers from improper use and events, such as Denial of Service (DoS), virus attacks, hijacking your server to relay spam email, and other troublesome email requires a vigilance on the part of every FirstClass administrator.
Before we discuss the specifics of configuring Internet Services to ensure security, let's look at some general approaches to security:
• physically securing the server machine
The first step in preventing abuse is to make sure unauthorized individuals cannot tamper with the Internet Services machine. These abuses include either physically disabling the machine or loading and reconfiguring software in a way that makes it vulnerable to attack.
• securing the server machine from unauthorized use
In cases where physical security of the Internet Services machine is not possible, you should secure the machine from unauthorized use. This may include setting good passwords for the machine and applying user/group privileges and conference permissions to control what users can do.
For example, you can run Internet Services as a Windows NT service or as a Unix daemon. This allows you to leave the machine logged in with no concern of unauthorized entry.
• securing the server from network attacks
The next step in preventing Internet Services abuse is at the operating system (OS) level. You should always run your OS vendor's latest security patches to prevent low-level network Denial of Service (DoS) attacks.
Next, disable all other network protocols on the Internet Services machine, as any software that accepts network connections is a possible doorway into your system. When Internet Services is running, it should only use those network ports it is configured to serve. File sharing, network logins, network management protocols, and other web servers are all frequently exploited to gain a foothold on the machine.
• keeping troublemakers off your system
If your system logs reveal certain IP addresses are testing your security (for example, trying to infect your system with the Code Red virus or usurping your system resources) you should consider blocking them. It's better to ban these IP addresses than to let them user your server for their own activity. The Status tab on the Internet Services Monitor form has an Abuse indicator light with IP address and host name. This allows you to easily spot suspicious activity and block the offenders.
Be careful when blocking IP addresses to be sure they are not either a friendly site or an IP address handed out temporarily (for example, by Dynamic Host Configuration Protocol (DHCP) from an Internet provider). There are quite a few good Internet sites that can be used to verify the origin of IP addresses (for example, www.samspade.org).
• clamping down on SMTP relaying
If you don't require SMTP relaying on your machine then don't turn it on. If you need it, turn it on in the most restrictive way possible. SPAMmers like finding an open relay, as it legitimizes their junk mail by making it appear to be coming from your server. This allows them to send mass mailing using your bandwidth. As the administrator, you want to reject SPAM as early in the process as possible without actually blocking legitimate email.
How Internet Services security works
Internet Services security features are layered and execute in this order:
1 SMTP AUTH, which verifies credentials for POP3 and IMAP4 clients to relay off your FirstClass site.
2 Filter documents, which accept or reject mail based on the sender's IP address or domain name that appears in your filter documents.
3 IP automatic block, which automatically blocks IP addresses (temporarily) that reach a preset score based on the Abuse subtab settings on the UCE/Spam tab on the Basic Internet Setup form. You can also set the duration you want to block the IP address on the Abuse subtab.
4 IP temporary block, which manually flags suspicious IP addresses, which you can view on the Security tab on the Internet Services Monitor form. You can manually block the offending IP addresses once you've identified them.
5 Reverse DNS Lookup, which queries the DNS name against an incoming IP address for validity, if you have it this option enabled on your system (Junk subtab on the UCE/Spam tab on the Basic Internet Setup form).
6 RBL (Realtime Blocklists) lookup and SURBL (Spam URI Blocklists), which queries the RBL services of your choice (RBL subtab on the UCE/Spam tab on the Basic Internet Setup form).
7 SMTP rules, which scans and inserts a message header, message body, and spam score (assigns a number) to incoming email based on its content.
8 User-created rules (Setting up automatic mail handling), which handle incoming mail based on a user's personal mail rules.
 Handling spam
You can combat spam with:
• filter documents
• mail rules
• RBL/SURBL lookups
• DNS lookups of IP addresses.
Users can also create their own mail rules to block particular mail.
Filter documents
Filtering unwanted IP addresses and domain names is one of the most important steps you can take to fight spam and abuse. You do this by using and creating filter documents in the Filters folder, located inside the Internet Services folder on the administrator’s Desktop. If you wish to use filter documents to block addresses, you must enable "Reject connections based on Filters" on the Connections tab of the Basic Internet Setup form.
 Warning Enabling the "Reject connections based on Filters" option blocks all connections to Internet Services, not only SMTP connections.
The Filters folder holds filter documents (and rules documents) that can contain exact IP addresses, IP masks (groups of similar IP addresses), mail addresses, and domain names from individuals or sites you wish to trust or block, as well as protocols. Coupled with enabling the "Reject connections based on Filters" on the Connections tab on the Basic Internet Setup form, this is FirstClass's primary feature to help control unwanted spam on your system.
You can update your filter documents whenever necessary.
The Filters folder overrides any other site configuration. For example, if you have enabled RBL lookups on your site and your RBL service finds an IP address trying to connect to your system on their "bad" list, Internet Services will accept the connection if you've placed that address in your Filters folder as a trusted site.
Alternately, if you've blocked a site in your filter document the connection is refused immediately, using the least possible processing power and system resources. This makes IP blocking especially useful for ridding yourself of troublemaker machines on the Internet, whether they are trying to hack into your system or deny service to your users.
Below are examples of the proper syntax to use in your filter documents.
Syntax for blocked IP addresses, domain names, email addresses, protocols
You can create filter documents in either FirstClass format or as simple text files and upload them to the folder. The format of a filter document conforms to that used in various Internet anti-spam sites, with one entry per line and domains optionally prefixed with an @. In all cases, begin your comments with #. Here are some examples of the proper filter
syntax:
• 123.123.123.123
#This blocks mail from 123.123.123.123.
• 123.123.12.*
#This subrange blocks mail from every SMTP server whose IP address starts with 123.123.12
• 111.*.*.*
#This mask blocks mail from every SMTP server whose IP address starts with 111.
• 123.123.12.123/130
#This range blocks IP addresses from 123.123.12.123, 123.123.12.124, .... 113.123.12.130.
• 123.123.12.123 - 123.123.12.130
#The same block as the previous example but in a different format.
• @spamdomain.com
#This domain block refuses mail from any server that declares itself part of the spamdomain.com domain or any user@spamdomain.com.
• spamdomain2.com
#The same as above with slightly different syntax.
#This email block refuses any email from this address if it appears in either the SMTP MAIL FROM or RFC-822 From: header.
• *.badplace.com
#This wildcard allows you to block any subdomain of badplace.com. This format is the same format used in the rules.SubjectBlock document.
• regexp:[bB][pP][0-9*\badplace\.com
# This blocks any subdomain of badplace.com that starts with "bp" or "BP" and has zero or more digits (for example, bp.badplace.com, bp1.badplace.com, bp12345.badplace.com, and so on)
• pop3,imap:192.168.123.234
#This blocks only pop3 and imap connections from 192.168.123.234.
Syntax for trusted IP addresses, domain names, email addresses, and protocols
You can make an IP address or domain name trusted by placing a "+" sign in front. If you have the address trusted, Internet Services will not apply any mail rules to the message. Trusted IP addresses override blocked IP addresses. If you need to block a group of IP addresses but trust a single IP address within the range, make sure you trust that particular IP address or domain name.
Trusted IP entries take one of two forms: a single IP address per line or an IP mask:
• +111.222.111.222
# This trusts mail from 111.222.111.222.
• +111.*.*.*
# This mask trusts every IP address that starts with 111.
• +*.goodplace.com
# This trusts any subdomain of goodplace.com or user@goodplace.com.
• +smtp:192.168.123.123
#This trusts only smtp connections from 192.168.123.123.
Mail rules
Along with the filter documents, the Filters folder contains these rules files: rules.MailRules, rules.AttachmentBlock, and rules.SubjectBlock files. You can use these files to control and manage spam and junk mail, delete or block unwanted attachments, and stop messages containing illegal phrases or words. These files are discussed in depth in "Using SMTP mail rules to handle spam".
 CautionThe rules.MailRules file is a heavily coded document and may be confusing to understand at first. We highly recommend that you become familiar with this document and specifically read the included commented lines before you customize the Mail Rules subtab or change any values in the rules.MailRules file.
The rules.MailRules file examines the content of incoming SMTP message headers and performs specific actions to score and reject spam deliveries and mark suspicious messages.
You can control how the rules.MailRules scores spam by setting specific parameters on the Mail Rules subtab on the Basic Internet Setup's UCE/SPAM tab. By default, the rules.MailRules file contains code that picks up the values set on this tab and performs an appropriate action in response to the set values and how you've configured the rest of the tab.
RBL/SURBL lookups
You can query the IP address of any SMTP server that connects to your site using a Realtime Blocklists (RBL) service and Spam URI Realtime Blocklists (SURBL), to see if the IP is a known source of spam mail.
RBL lists check to see who is connecting to your server. A RBL service compiles lists of IP addresses responsible for spam and from sites whose servers are hijacked for spam relay.
SURBL lists check the domain names inside of messages sent to your server. If a spamming domain is detected, the shipping rule.MailRules document adds 101 to the spam score and SPAM_LINK to the spam tests. Internet Services caches both RBL and SURBL lookups to reduce the load on your system. SURBL is especially useful, if you have a front end on your system. If you enable services, you should not notice a significant amount of extra load on your system.
These services inform you of bad and questionable IP addresses during the SMTP connection phase and let you deal with them as you see fit, using the available Internet Services options.
Choosing the right services for you
There are many RBL services from which to choose. Some are better than others and most have different degrees of aggressiveness, specialization, and cost. Before you enable RBL, you need to do some legwork to decide which services best suit your organization's needs. Many RBL services also offer SURBL lookups.
We can't recommend one service over another, but we do recommend taking a look at these web sites for a comparative analysis of different RBL hosts:
This site compares different blacklist services and suggests a few used by the author.
This site provides lists of blacklist services that specialize in blocking different kinds of spam and open relays.
We also recommend choosing two or three services, as no one service lists all the potential "bad guys" on the web.
Although only you can determine which setup is best for your site and your users, here are a few thoughts to keep in mind:
• use a RBL service that is good at identifying the source of the SPAM that you receive
• keep an eye on the RBL section of the Internet Monitor (see below)
• replace RBL services that don't seem to detect much SPAM
• educate your users on how to create useful personal mail rules.
Enabling RBL/SURBL on your site
After you've chosen your services, configuring the RBL feature is easy.
 Note Any IP addresses or domains that you have trusted in a filter document always overrides anything you've enabled in your RBL options. This means that if an incoming IP address is identified as a spammer by one of your RBL services but you've also listed it as trusted in a filter document, Internet Services will still pass it to the server for processing.
To enable RBL/SURBL:
1 Select "Enable RBL lookups" or "Enable SURBL lookups" on the RBL subtab on the Basic Internet Setup form.
We recommend enabling both options. Internet Services caches lookups to reduce the load on yoru system.
2 Fill in the domain names of the RBL/SURBL hosts you want to use.
3 Type in your preferred text in "NDN text".
This field should contain the text you want rejected senders to see in their NDNs. For example, "You have been tagged by our RBL service. Message not delivered. Please contact myRBLhost.com for further information."
In this configuration, if an incoming IP address is found on a service's RBL list (and it is not listed as trusted in one of your filter documents), Internet Services will refuse the message from that server. Since the listed RBL services are checked in order from top to bottom, as soon as an address is found on a list the checking stops. For example, if a message passes the first entry (rbl.spamcop.org) but is tagged by the second entry (sbl.spamhaus.org) no further checking is done.
The reduction in incoming spam makes up for the additional load on your server of having to connect to the RBL host in processing each connection. However, there may be a slight increase in the number of active SMTP inbound connections with this feature enabled. To further help reduce the load on your system, Internet Services has a built-in feature that caches RBL lookups, which eliminates the need for repeated lookups.
What if I don't want to reject a sender immediately?
If you don't want to reject sites that fail the RBL lookup, you can insert a warning header into the incoming message instead. To do this, select "X-RBL-Warning header instead of NDN" on the RBL subtab on the Basic Internet Setup form:
NoteIf you use this header option, you still need to select "Enable RBL lookups" on the RBL subtab on the Basic Internet Setup form.
If you select this option, the contents of "NDN text" are inserted as the data portion of the "X-RBL-Warning" header in the offending message. In this case, you should replace the "NDN text" with something that identifies the RBL site that triggered the header and is easy to parse. This will make it easier for your users to write FirstClass server mail rules to process these messages. Also, if a user is unfamiliar with a sender who's been identified as possibly "bad", and doesn't want to continue to receive mail from them, you have the option of rejecting the IP address in your filter documents.
If you go with this option, your users must choose the View > Show Internet Header option from the FirstClass menu to see if a message has been tagged in their incoming mail.
This is part of the Internet header of a message:
 In what order should I list my RBL services?
The order in which you list your RBL services depends on the type of spam your site normally receives. If the majority of your spam is from a particular type of spammer (for example, medical or financial) you should choose a couple of good RBL services that specialize in identifying these perpetrators and place these services first and second on the RBL list. You can then place a service that specializes in other types of spam (or even a more generic type of service) to catch any remaining spam that hits your site.
If you want to reject (NDN) all tagged connections, use an aggressive RBL service. This guarantees that Internet Services will not pass spammers to the server. However, you also run the risk of NDNing legitimate messages. This is a very strict setup but, if your site is getting spammed to death, it may be necessary. If you are concerned about being overly aggressive, you can choose a more forgiving service.
Remember, the earlier a RBL service identifies a spammer the less work for your system. For example, if your first service does not tag a message, Internet Services goes to the next available service entered in the list. This uses more resources and may slow down your system. Whereas, if your first service identifies a message as spam, Internet Services stops the hunt chain and no more work needs to be done.
If you choose to inject the X-RBL-Warning header instead of automatically rejecting a connection, ordering the RBL services from least aggressive to most aggressive puts a choice into the hands of your users. They can set personal mail rules to handle mail tagged by the RBL services to sort through manually at a later time in containers other than their Mailboxes.
Only you can determine which setup is best for your site and your users. A good approach is to:
• use a RBL service that is good at identifying the source of the SPAM that you receive
• keep an eye on the RBL section of the Internet Monitor
• replace RBL servers that don't seem to detect much SPAM.
How and where do I track RBL activity on my system?
You can track your RBL activity and make decisions based on this information using the Security tab on the Internet Monitor, located in the Internet Services container on the administrator's Desktop.
 The information displayed in this section of the form lets you know:
• which RBL services are active
• how many times the services have been accessed
• how many addresses the services have detected on their lists
• the percentage of lookups to identified addresses (this indicates the effectiveness of your RBL services)
• the number of times a service did not respond to a lookup
• average response time of a lookup
• longest response time of a lookup.
The Off buttons let you temporarily disable lookups on the RBL service without having to permanently remove them from the Basic Internet Setup form. This is useful for testing purposes or if one of your RBL services is under a DoS attack. The Reset button will reset your RBL statistics.
DNS lookups of IP addresses
You can query (reverse DNS lookup) the IP address of any connecting SMTP server that tries to connect to your site for an associated domain name. If no domain name is found, Internet Services refuses mail from that server. To select this feature, choose "Reject unknown domain names" on the Junk subtab on the Basic Internet Setup form.
Since this task relies on querying the DNS server on each inbound SMTP connection, you may find that it puts an extra load on your system. Make sure your DNS server is functioning well in order to maintain good performance.
Spam logging
When Internet Services refuses to accept a message, an entry is added to your server statistics file. Spam logging is enabled by default.
Here is an example of a spam log entry:
Spam 27 10/22/2001 12:27:54 PM localhost 127.0.0.1 terry@127.0.0.1 Sender Extra
Spam: keyword
The keyword for these entries is always "Spam"
• 27: FirstClass user ID
Usually the Internet Services gateway userid 1000000000
• 10/22/2002: the date
• 12:27:54 PM: the time
• localhost: the host name
This is declared by the remote host in the SMTP.
• 127.0.0.1: the IP address
The remote host IP address.
• admin@127.0.0.1: the mail address
The mail from: field in the SMTP conversation.
• Sender: the reason code
The reason code can be one of:
• MailRule
• Sender
• RBL
• ReverseDNS
• Host
• RelayReject.
Extra: the extra information
Extra information will contain:
• MailRule type - any NDN text sent
• RelayReject type - the address being relayed
The rcpt to: field in the SMTP conversation.
NoteRelayReject is not logged when all relaying is disabled.
Handling relaying
Relaying occurs when Internet Services receives a piece of mail through SMTP that is not destined for a user on your system.
If your site does not need to relay mail, we recommend that you disable the option on the Relaying subtab on the UCE/Spam tab of the Basic Internet Setup form. If you choose this option, no SMTP server can relay off your site even if it provides the proper credentials (user ID and password - SMTP AUTH) or you have the server IP address in your Filters folder. This setup is easy to administer and extremely secure, as your system allows absolutely no SMTP relaying.
Preventing unauthorized mail relaying
If you choose to allow relaying, you can control which individual users or groups can relay mail using the privileges on the User information form and the Group privileges form respectively. To set this up, you must:
• clear the "Disable all relaying, including SMTP AUTH and trusted IPs" field on the Relaying subtab on the UCE/Spam tab
• clear the "Allow mail relay" field on the All Users group form
• select the "Allow mail relay" field for any individual users or groups on the User information form and the Group privileges form respectively.
Allowing relaying for specific purposes
There are two scenarios where you may need to support relaying:
• you need to support POP3 or IMAP4 users on your system who send mail outside of your organization
• your Internet Services acts as the Internet contact point for a group of SMTP servers.
If your site needs to relay for POP3 or IMAP4 users
If you need to support POP3 or IMAP4 users who use your FirstClass server to relay, we recommend using SMTP AUTH, which is an extension to the SMTP protocol. Using this protocol, when a user sends mail using a POP3 or IMAP4 client, Internet Services will prompt the user for his login credentials (user ID and password authentication). Since FirstClass supports the SMTP AUTH protocol, we recommend that you instruct your users to enable it on their POP3 and IMAP4 clients.
Unless you explicitly disable relaying, Internet Services will do SMTP relaying for those who supply credentials.
What if I get blacklisted as an open relay?
Because of the proliferation of spam and the difficulty in stopping it, there are a number of organizations (including RBL suppliers) who aggressively identify open relay sites and add them to their lists. If your site is blacklisted, do the following:
1 Check your relay settings (Internet Services and user privileges).
You probably got blacklisted because spam came from your site. Lock things down using the methods outlined in this section and try to isolate the problem. If you can't locate the problem, contact the blocking organization and ask for help.
2 Ask the blocking organization to retest your site after you've located and fixed your relaying problem.
3 Check the trusted IP addresses in your filter documents.
There are some organizations, for example ORBS, that use flawed relay tests that assume your mail host is "sendmail". If you have configured your system correctly and you still fail their test you should try these options:
• reconfigure Internet Services to act more like sendmail
The main issue with these tests is that Internet Services absorbs some attempts to relay as if it might be delivering the message, when, in fact, it later delivers an NDN. Since the tests do not wait for the NDN, they are fooled into thinking the relay worked. By choosing Aliases only at "Inbound mail addressing" on the Advanced Directory form, you force Internet Services to reject these efforts as they come in:
Using this option comes at the expense of your need to manually configure aliases (or set up automatic aliasing) for your Internet mail users on the Advanced Directory form.
• inform the blocking organization that you are not relaying, and prove it to them by having them try to relay off your site to some destination account.
The better organizations may respond reasonably to this sort of approach.
Controlling unwanted connections
Many sites experience attempts from SMTP servers illegally trying to gain entry to their system. For example, Denial of Service (DoS) attacks (which generate so much traffic that legitimate sites or users can't connect) and attempts to guess system passwords are the most common ways hackers try to cause trouble.
You can control unwanted outside connections using these options:
• permanently block suspicious IP addresses to your filter documents in the Filters folder
• temporarily block IP addresses that register strikes against your server by appearing to guess your passwords
• temporarily suspend unwanted connections
• monitor system abuse and configure Internet Services to trigger warnings from unwanted connections using the settings on the Abuse subtab on the UCE/SPAM tab of the Basic Internet Setup form.
In addition, Internet Services automatically performs password attack detection using SMTP AUTH.
Temporarily blocking unwanted IP addresses
If your FirstClass site connects to the Internet, you will inevitably experience unwanted connections from IP addresses that repeatedly try to log into your system with incorrect user IDs or passwords.
Internet Services has a "strike out" option that temporarily blocks unwanted IP connections using this entry in the rules.MailRules file (located in the Filters folder on the administrator's Desktop):
.: IF ($spamlevel > $HighSpamMax && $XtremeCausesNDN) STRIKE # this action must come before the NDN action
and the parameter settings on the Junk subtab on the UCE/Spam tab of the Basic Internet Setup form.
Note To enable the STRIKE rule in the rules.MailRules file, you must select "Extreme causes NDN" on the Mail Rules subtab on the UCE/Spam tab.
Basically, if your site receives a certain number of strikes (bad connection attempts) from an IP address within a certain period of time, Internet Services adds it to a temporary block list for a certain period of time, which you set on the Junk subtab on the UCE/Spam tab. You can log the temporary list to a permanent file and clear entries from the Control tab on the Internet Services Monitor form.
For example, say you have this setup on your system:
 Internet Services will allow an offending IP address to attempt to connect to your site three times with less than one minute between attempts, before blocking it for five minutes. So, if the first connection happens at 58 seconds, the next connection at 57 seconds, and the third connection at 59 seconds, Internet Services knows that all three connections are from the same troublesome address and will block it for the prescribed amount of time.
If the IP address tries to connect to your site in intervals greater than one minute (for example, every 64 seconds between attempts) Internet Services resets the counter after each attempt and begins the process over. Since the offending address waited longer than the one minute between each attempt to try to connect to your site, Internet Services does not consider it the same offending address and will not strike it out. Therefore, it is not blocked for the amount of time you've set on "Amount of time to block struck out IPs".
 Tip If you can establish that the offending IP address belongs to a particular user or organization, you can add it to your filter list so you can block it permanently. However, most hackers use IP addresses that cannot be traced back to the correct origin.
Temporarily suspending unwanted IP addresses
Along with temporarily blocking unwanted IP addresses, you can temporarily tie up their resources in a virtual "blackhole". Using this approach, you can dissuade attackers from trying to access your system. When an offending IP address tries to connect, Internet Services discards any data sent while producing a slow, timed stream of characters to keep the connection alive. This way you tie up their resources and slow their ability to hit your site and other sites.
Note Some RBL services request that you implement this feature in order to use their service.
To blackhole unwanted connections, you must select "Reject connections based on Filters" on the Connections tab on the Basic Internet Setup form and have the IP address listed in your filter documents in the Filters folder. You then set the parameters in the "Connection black hole" section on the Connections tab.
 You can flush suspended connections on the Control tab on the Internet Services Monitor form.
Sending secure mail
FirstClass supports Secure Multi-Purpose Internet Mail Extensions (S/MIME) email encryption to send and receive encrypted and signed messages by using digital certificates. These certificates contain a public key, a private key, and a digital signature. The private key is used to decrypt message content, the digital signature is used to sign or verify the message, and the public key is used to encrypt message content. For information on sending secure mail, see Making messages secure in the Client help.
You can think of a signature as an individual's fingerprint; a unique identifier only for that person. This signature allows you to send and receive messages and be secure in the knowledge that you are sending and receiving information from the correct person.
To use S/MIME on your system, your users must:
• install a certificate from a certificate authority
• export the certificate to a file that they will give to you to upload to the server in the SSL Certificates folder
After your user exports a digital certificate and sends it to you, you must place it in the Internet Services/SSL Certificates folder on the administrator's Desktop and rename it using the your user's email address (for example, roy@huskyplanes.com).
Note We recommend that you become familiar with how to install and export certificates, as you may be required to walk your users through the process.
• exchange signed S/MIME messages to exchange public keys between themselves and their recipients
After your users complete the above tasks, you may need to:
• install a root certificate
If your user can't include the root certificate in his exported certificate, you may need to request a Root certificate from the same certificate authority as the user's certificate and place it in the Internet Services/SSL Certificates folder.
Note Depending on whether your user gets his certificates from more than one certificate authority, you may need different Root certificates and possibly Intermediate certificates. Speak with the certificate authority to verify your requirements.
Root and Intermediate certificate names must start with the characters (ca) followed by a period (.) and be less than 64 characters in total. For example, ca.thawte.
• upload all certificates the user receives from senders.
When your user sends an initial S/MIME mail message to establish a secure channel with his recipient, Internet Services automatically attaches the public key part of the certificate to the message and the recipient follows the same process.
Your user must send you the certificate he receives from his recipient and you must put it in the Internet Services/SSL Certificates folder on the administrator's Desktop. You must then rename the file to match the sender's email address (for example, lyn@othersite.com).
Using a secure content site
A secure content site is an important security feature that provides an added measure of protection against system attacks. Its purpose is to allow administrators to set up read-only sites to be used for file downloads. This prevents potential attacks on the system where an attachment or uploaded file may contain malicious HTML that executes an attack on a user when it is opened through the web. By moving all file download activity to a read-only site, the various browsers' cross site scripting defenses act to prevent this potential threat.
Setting up a secure content site
Note This process is required for each secure content site you wish to set up.
To set up a secure content site:
1 Register a domain.
Register a secondary domain and point it at Internet Services. For example, if the main site is www.site.com, the secondary domain might be download.site.com.
 NoteIf the site has an SSL certificate, then depending on the type of certificate, it may be necessary to get an additional certificate for the secondary domain as well.
2 Update the Multiple Sites & Languages form.
Add a new line to the Multiple Sites & Languages form for the secondary domain. Give it the same "Web site alias" as the primary site. Set "Authentication" to Read Only.
3 Update the user.HeaderMatach document.
Update the user.Headermatch document to add a line for the new domain:
<sitename>: SET contentsite = <secondarydomain>
Scanning for viruses
Using the Symantec AntiVirus (AV) engine, you can scan inbound and outbound mail attachments (sent or received through Internet Services) for viruses and have Internet Services delete the infected ones before delivery to your user's Mailbox.
Once you have the AV software and licenses, you load the software on a separate machine. You then configure your Internet Services machine (and any clustered machines) with the IP address of the AV machine, on the Antivirus tab on the Advanced Mail form.
WarningDo not enable the options on the AntiVirus tab unless you are running the Symantic AntiVirus Scan Engine.
Once you complete this task, Internet Services feeds any inbound or outbound attachments to the AV machine, where the AV engine provides either a pass or fail indication.
Based on this information (and depending on whether the message is inbound or outbound), Internet Services either suppresses the attachment and adds a warning text, issues an NDN, or delivers the email with attachment to the server. You set the warning text for both inbound and outbound messages on the Antivirus tab on the Advanced Mail form.
If the AV engine detects an infected attachment on an inbound message, Internet Services deletes the attachment, replaces it with warning text, and continues to send the message to the server and subsequently to the recipient's Mailbox.
If the AV engine detects an infected attachment on an outbound message, Internet Services stops sending the message and returns an NDN with warning text to the sender:
 You can also optionally set the name of the warning text attachment in the rules.AttachmentBlock document. The name of the file must start with an equal sign followed by the new filename (maximum 63 characters.) Here is an example in the rules.AttachmentBlock file:
# This file contains a list of unacceptable file name/file type and creator patterns, one per line.
# It also contains some 'helpful' text that replaces the attachment.
#
# The help text is one or more lines that start with a colon.
# The optional name for the replacement attachment name is given
# on a line that starts with an equal sign (default is BlockedAtt.txt)
=VirusHasBeenDetected.txt
# The attachment names are case-insensitive, and use the DOS wildcard convention
# of * and ?
# Macintosh file type and creator patterns can be specified as well,
# using the syntax 'TTTT:CCCC' where TTTT is the file type, and CCCC
# is the creator. Use ? as a wildcard character.
:The attachment \@ that would have been here has been discarded,
:because it's name or type matched an entry that the Administrator
:considers dangerous or unacceptable.
*.exe
*.scr
'APPL:????'
Using the SMTP submission port
The SMTP submission port (587) separates personal (submission) user messages from server to server messages and requires users to authenticate (log in) to send messages through the submission port. It also makes it possible to treat these messages differently in other ways. For example, you don't need to do reverse lookups on these messages and you can run different mail rules on them and add in missing message IDs.
You only need to use this port if you have users on POP or IMAP whose Internet service providers have started blocking port 25.
To configure and activate the submission port, fill in the Submission tab on the Advanced Mail form.
Authentication options
Internet Services supports three different authentication options when submitting mail messages via SMTP (either port 25 or the SMTP submission port 587): LOGIN, PLAIN and CRAM-MD5. LOGIN and PLAIN are unsecure when used over an unencrypted (non-TLS) connection, and so their use should be disabled when an SSL certificate is installed for the SMTP server. The configuration choices are:
• SMTP authentication disabled
No authentication allowed.
• All authentication methods allowed on any connection
The old default. Reasonably secure for clients that choose CRAM-MD5.
• CRAM-MD5 allowed on any connection, Plain text allowed on TLS connections only
The new default. Reasonably secure for non-TLS connections.
• CRAM-MD5 allowed on any connection, Plain text disabled
Reasonably secure. Should be the choice for sites without an SMTP SSL certificate.
• CRAM-MD5 allowed on TLS connections only, Plain text disabled
The most secure.
"Reasonably secure" means the password is undetectable until CRAM-MD5 is broken.
Adding SSL certificates to your site
SSL certificates are used in the transmission of sensitive information on the Internet using the Secure Sockets Layer (SSL) protocol.
When a web browser points to a secured domain, an SSL handshake identifies the server (web site) and an encryption method is established. By convention, web pages that require an SSL protocol connection start with HTTPS instead of HTTP and the web browser will show a lock indicator somewhere in the browser window when displaying those pages.
You get SSL certificates from a certificate authority. Check your browser options or do an Internet search for a list of certificate authorities.
The types available include individual certificates for subdomains (www.mysite.com, mail.mysite.com) and wildcard certificates that cover everything under a domain name (*.mysite.com). If you have different domain names, you will need separate certificates for each.
Because the SSL handshake occurs before the HTTP request, each SSL certificate used for web servers is tied to an IP:Port pair. Since it's difficult to specify the port for HTTPS connections, this effectively means you need a separate IP address for each web site that uses an SSL certificate. This doesn't mean that you necessarily need multiple Network Interface Controllers (NICs) though. Your certificate authority can advise you further about what certificate(s) and configurations best suit your needs.
Obtaining an SSL certificate
1 Start FirstClass Designer (Windows version).
2 Choose File > Create SSL Certificate.
3 Type a password.
The password can be any combination of letters and/or numbers. Record the password for later use.
4 Fill in the Certificate Request Information form.
You must fill in every field.
5 Click OK and follow the prompts.
Text for both an RSA private key and a certificate request is generated. When prompted, copy both to a text file and save for later use.
6 Request a certificate on your chosen certificate authority’s web site.
When prompted, paste the text starting with "----BEGIN CERTIFICATE REQUEST----" and ending with "----END CERTIFICATE REQUEST----" from the text file you created above into the field provided.
If asked what type of web server you are using, select "Other", or "Apache" if "Other" is not available. This information is gathered by certificate authorities for marketing purposes only and does not affect the certificate you receive.
You will receive a link from the certificate authority for downloading your certificate.
After you've downloaded your certificate, you need to create a certificate document.
Creating a certificate document
1 Create and save a new document in Internet Services/SSL Certificates.
Give it a meaningful name ending with .cert, .crt, or .pem (for example, certname.cert).
2 Paste the text from the certificate you received, starting with "----BEGIN CERTIFICATE----" and ending with "----END CERTIFICATE----", into the document.
3 Type password: yourpassword below the certificate text, where yourpassword is the password you chose when you created the certificate request.
4 Paste the RSA private key text from the text file you saved earlier, starting with "-----BEGIN RSA PRIVATE KEY-----" and ending with "-----END RSA PRIVATE KEY-----", below the password text.
When completed, your certificate document should look something like this:
-----BEGIN CERTIFICATE-----
MIIDLD ... Cji7WnsTzuXX
-----END CERTIFICATE-----
password: pw4sitecertficate
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBA ... VhP/PxFg
-----END RSA PRIVATE KEY-----
If you are issued an intermediate certificate
Some certificate authorities issue intermediate certificates. If you receive an intermediate certificate you must place it in a separate document at the same time that you complete your server certificate document, and reference it in your server certificate document. To do this:
1 Create and save a separate document in the SSL Certificates folder.
Give it a meaningful name, starting with ca. and ending with .cert, .crt, or .pem.
2 Copy the intermediate certificate you received from the certificate authority into the new document.
3 Open your site (or server) certificate document.
4 Type cacertificate: ca.yourcertificatename below the password text, where yourcertificatename is the name of the document in which you saved the intermediate certificate.
Your site certificate document should now look something like this:
-----BEGIN CERTIFICATE-----
MIIDLD ... Cji7WnsTzuXX
-----END CERTIFICATE-----
password: pw4sitecertficate
cacertificate: ca.intermediatecert.cert
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBA ... VhP/PxFg
-----END RSA PRIVATE KEY-----
Activating SSL certificates
After you've downloaded your SSL certificate and created your certificate document in Internet Services/SSL Certificates, you need to set the status of the certificate to activate it.
To do this:
1 Fill in the SSL information and set the status as directed on the following forms:
NoteIf you are running clustered services on your system, configure the forms for each cluster.
2 Restart Internet Services.
You should now see the line "Initialized 1 HTTPS listeners" in your Internet Services window.
NoteWhen you enable HTTPS, extended server-side include (XSSI) variables that describe the connection become available (are set) and can be used in XSSI scripts. Internet Services supports all industry standard XSSI variables, with the exception of SSL_VERSION_INTERFACE. Advanced information about the variables used in Internet Services can be found on FCOL at Conferences/Peer to Peer Support/FirstClass Webmasters/FAQs.
| ||||||||||||||||